home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re[2] Part Server < prev    next >
Encoding:
Internet Message Format  |  1996-07-10  |  2.8 KB  |  [TEXT/ttxt]
  1. Subject:     Re[2]: Part Server
  2. Sent:        7/10/96 11:17 AM
  3. Received:    7/10/96 11:42 AM
  4. From:        Joel Robertson, joel_robertson@AICI.COM
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. >Chris Hunt wrote:
  9. >> I have a similar problem; I want to create a service and it must be 
  10. >>OpenDoc aware.  My part service will be focused on serving the document as 
  11. >>a whole (I could extend its scope to be cross-document, but I don't need 
  12. >>to here).  I'm writing a faceless part editor that is communicated with 
  13. >>via AppleEvents; the preferred method of interprocess communication for 
  14. >>MacOS 8.  I'm also conforming to the AppleEvent Registry Core Suite fully 
  15. >>('cause its the right thing to do!).
  16. >>
  17. >> So long as my service doesn't require any co-operative services, the 
  18. >part >editor should be able to run as a pre-emptive task in the future 
  19. >>(providing that OpenDoc enables this to happen with MacOS 8).
  20. >>
  21. >> I'd be interested in any feedback to my approach to writing services.  I 
  22. >>suspect that other services would be written in a similar fashion.
  23.   
  24.   
  25. >I'll say this again: I don't think it is a good idea to try to write a 
  26. >"faceless" OpenDoc part. I also think that trying to make such a part 
  27. >scriptable will be seriously confusing to users.
  28.   
  29. >There are a variety of specification mechanisms that can be used to target 
  30. >a specific part. Most of these mechanisms are dependent on the human 
  31. >user's ability to describe the target part's relationship to the 
  32. >containment hierarchy. This is not only difficult to do with an invisible 
  33. >part, but the presence of the invisible part has the potential to 
  34. >introduce unexpected behavior. For example : embedded parts can be 
  35. >referenced by index. Even an invisible part will have an index. How does 
  36. >is a user expected to script a document that potentially has multiple 
  37. >invisible parts embedded in it? How does the user change the name of the 
  38. >invisible part if they can't get to its Part Info dialog?
  39.   
  40. >I seriously suggest you investigate alternative implementations. I'm still 
  41. >not sure why extensions or even a shared library won't work in this case.
  42.   
  43. >Greg Friedman.
  44.   
  45.   
  46. >___________________________________________________________
  47. >Greg Friedman       ODF Engineering        Apple Computer
  48.  
  49. I haven't even gotten my feet wet with OpenDoc/ODF, so my (naive?) question 
  50. is, how then would a spelling checker (either an as-you-type or entire 
  51. document/selection kind) or grammar checker be implemented in OpenDoc/ODF? I 
  52. was under the impression that these utilities would still be considered parts. 
  53. Although they wouldn't have their own content (faceless?), they may have menu 
  54. items for setting document-level preferences and invoking the utility on the 
  55. parts which have content (textual content, in this case).
  56.  
  57. Joel Robertson
  58.  
  59.  
  60.